1. Field of the Invention
The present invention relates generally to computer programming, and in particular, to a method, apparatus, and article of manufacture for dynamically binding native assemblies from platform agnostic managed assemblies.
2. Description of the Related Art
Using Microsoft's .NET Framework™, developers create managed assemblies, which are dynamic linked libraries (DLLs) that are executed by the .NET Framework. Managed assemblies can be compiled to be platform agnostic. This is known as an assembly that targets “Any CPU”. This is desirable because the same binary assembly can be deployed to any platform, such as Win32™, x64™, and IA64™. Deployment means copying files to a target computer and installing the developer's work onto that computer. Typically, because of reflection, a managed assembly can only directly access other managed assemblies. In this regard, one managed assembly can inspect, find interface points, parameters, and other data about a single other managed assembly.
There are times when the developer needs to use code that is better suited, for whatever reason, in native assemblies. Native assemblies are traditional DLL's that are loaded and executed by the Windows™ operating system. Native assemblies are practically always platform-specific.
The fact that native assemblies are platform-specific introduces the problem when a developer needs to deploy custom native assemblies along with “Any CPU” managed assemblies.
Microsoft™ supplies a mechanism, DllImport™, that performs binding to native assemblies. Binding is the process of attaching an application program interface point from one assembly to another, allowing use of the bound assembly. DllImport™ is limited because it does not support run-time binding to various assemblies based on platform type. Further, to use DllImport™, developers must know the exact location of the native assembly when the managed assembly is written, and either add the location to the system path or utilize specific code that identifies the location.
Prior solutions require complex, hard-to-debug code. Also, prior solutions encourage code duplication, which presents further issues in extra cost and defect risk in maintaining multiple copies of each platform interface.
The prior art may employ one or more of the following methods to dynamically bind to native assemblies from managed assemblies:
(1) DllImport (also known as System.Runtime.InteropServices.DllImport) (described above and more fully described in msdn.microsoft.com/en-us/library/system.runtime.interopservices.dllimportattribute.aspx which is incorporated by reference herein). However, as described above, such a solution does not support run-time binding to various assemblies based on platform type;
(2) Avoid runtime dynamic binding by building distinct platform specific managed assemblies. This requires non-orthogonal deployment by platform type. In other words, separate source code is created for every platform;
(3) Duplicating the API (application programming interface) interface declarations in the managed code, once for each supported platform. An exemplary use of API duplication is set forth in stackoverflow.com/questions/1319849/setting-dllimport-programatically-in-c which is fully incorporated by reference herein;
(4) Writing only two copies of each API interface, regardless of how many platforms are supported, but have the program write new executable code (known as emitting) and execute that emitted assembly. An exemplary use of such a solution is described in www.codeproject.com/KB/dotnet/DynamicDllImport.aspx which is incorporated by reference herein. In other words, code is emitted/written at run time which determines which assembly to bind to. Such emitted code inspects the platform the code is executed on, the processor type, etc. and a just-in-time complier complies and writes out an intermediate language to bind to the native assembly. One of the problems with such a solution is security; and
(5) Manually writing code that loads the native assembly and binds to the entry point. An exemplary use of such manual code writing is set forth at www.codeproject.com/KB/cs/DynamicInvokeCSharp.aspx which is incorporated by reference herein.
Accordingly, a common practice is to utilize many distinct varieties of deployment platforms and further utilizing development platforms that may be different than deployed systems. Accordingly, there are many different code bases, one for every different platform. Prior art techniques require different deployments for the different platforms. What is needed is a method for utilizing both managed and native assemblies using a single deployment and single code base while supporting run-time binding to various assemblies based on platform type.